Using Git - An Example
Basic Commands
You can see the version of Git you have installed with:
$ git --version
git version 2.27.0
Detailed help information in the form of a man page can be obtained about any subcommand by doing:
$ git help [subcommand]
For example, the two following statements produce the same result:
$ git help status
$ man git-status
You can get a basic list of Git commands by just typing git, which will give you the following list :
$ git
usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
[--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
[--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
<command> [<args>]
These are common Git commands used in various situations:
start a working area (see also: git help tutorial)
clone Clone a repository into a new directory
init Create an empty Git repository or reinitialize an existing one
work on the current change (see also: git help everyday)
add Add file contents to the index
mv Move or rename a file, a directory, or a symlink
restore Restore working tree files
rm Remove files from the working tree and from the index
examine the history and state (see also: git help revisions)
bisect Use binary search to find the commit that introduced a bug
diff Show changes between commits, commit and working tree, etc
grep Print lines matching a pattern
log Show commit logs
show Show various types of objects
status Show the working tree status
grow, mark and tweak your common history
branch List, create, or delete branches
commit Record changes to the repository
merge Join two or more development histories together
rebase Reapply commits on top of another base tip
reset Reset current HEAD to the specified state
switch Switch branches
tag Create, list, delete or verify a tag object signed with GPG
collaborate (see also: git help workflows)
fetch Download objects and refs from another repository
pull Fetch from and integrate with another repository or a local branch
push Update remote refs along with associated objects
'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
See 'git help git' for an overview of the system.
There are only a few global options that apply, those prefixed with -- in the presented listing. Many of the subcommands have their own options which are included in [ARGS].
If you cannot resist seeing the more complete set of commands, you can do:
$ git help --all
Master vs Main
What is master or main?
Master or Main is the default branch in a Git repository. This branch usually contains the stable, working code. When people clone a project, this is the branch they normally get.
Why was master used before?
In the past, Git automatically named the first branch master. Almost all old projects still have a master branch.
Why is main used now?
Many projects decided to rename master to main. This change is mostly about inclusive naming. Functionally, nothing changes — the code and behavior are the same. You can name the main branch anything:
- main
- master
- production
- stable
But Git and platforms like GitHub need a default name, and today that default is main.
Example Git command
Creating a new repository with main
git init # Create a Git repository
git checkout -b main # Create and switch to a branch called main
Existing project with master and switch to main
git branch -m master main # Rename branch locally
git push -u origin main # Pushes main to the remote repository
Instead of deleting master, you can copy it
git checkout master # Switch to master branch
git branch main # Create a new branch called main (copy of master)
git checkout main # Switch to the main branch
git push -u origin main # Push main to remote repository
For switching to another branch Git now prefers: git switch main instead of: git checkout main
Getting Started with Git
In this example we want to :
- create a local project
- let Git track changes
- see how Git notices file changes
- view history of changes
- understand benefit of sign commits
Create a project and initialize Git
mkdir git-test # create a new folder for your project
cd git-test # enter the project folder
git init # tell Git: “Start tracking this project”
After this:
- Git creates a hidden folder called .git
- Your project files are not changed
- Git just starts watching the folder
What is the .git folder?
ls -l .git
.git is Git’s brain and it stores:
- History of changes
- Branches
- Commits
- Configuration
You normally do not touch this folder, If you delete .git, your project is no longer a Git project.
Create a file and tell Git about it
echo some junk > somejunkfile # First command creates a file called somejunkfile
git add somejunkfile # Second command stages the file
Staging means: “I want Git to include this file in the next snapshot (commit).”
Check project status
git status
What Git is telling you
- You are on the master branch (could be main in new projects)
- This is the first commit
- The file is staged but not saved yet
Think of staging like selecting files before clicking Save.
Tell Git who you are
git config user.name "Another Genius"
git config user.email "a_genius@linux.com"
Why this is needed
- Git records who made each change
- Important for teamwork and open-source projects
You usually set this once globally, not every time.
Modify the file and see what changed
echo another line >> somejunkfile
git diff
What git diff shows are differences between:
- Last staged version
- Current working version
Output meaning (simplified):
+another line
+ → new content added
(if the case is removing a line)
-another line
- → removed the content
Git is showing exactly what changed and this is very useful before committing to double-check your work.
Commit the changes
git commit -m "My initial commit" # saves those files into Git history and (-m) adds a short message describing the change
After this:
- The file is permanently stored in Git’s history
- Git assigns a unique ID to this snapshot
Understanding commit output
1 file changed, 1 insertion(+), 0 deletions(-)
create mode 100644 somejunkfile
This means:
- 1 file was changed
- 1 line was added
- No lines were removed
- A new file was created
What if you don't use -m ?
git commit
This means:
- Git opens a text editor
- You must type a commit message
- If you close without saving, the commit is cancelled
Use -m for simplicity
A commit is a saved snapshot of your project with a message explaining what changed and who is responsible.
View commit history
git log
What git log shows
- Commit ID (long hexadecimal number)
- Author name and email
- Date and time
- Commit message
commit eafad66304ebbcd6acfe69843d246de3d8f6b9cc
Author: A Genius <a_genius@linux.com>
Date: Wed Dec 30 11:07:19 2009 -0600
My initial commit
What is that long commit ID?
It is a unique identifier (hash) with 40 hexadecimal characters (160-bit). Git uses this to track commits, not filenames
In practice: You usually use only the first 7–8 characters
git show eafad66
Signing off on commits
Why sign commits?
- Shows who approves the change
- Helps with legal ownership and licensing
- Common in open-source and company projects
git commit -s -m "My initial commit"
This adds a line like:
"Signed-off-by: Another Genius <a_genius@linux.com>"
- The signer may not be the author
- A reviewer or maintainer can sign
- Multiple people can sign the same commit
- Signing means you take responsibility
Simple git workflow
Edit files -> git add -> git commit -> Repeat